На сайте проекта VMware Labs появилась очередная полезность - утилита Workspace ONE Mobileconfig Importer. Она дает возможность импортировать существующие файлы конфигурации мобильных устройств (mobileconfig) напрямую в окружения Workspace ONE UEM как профиль Custom Settings. Также можно импортировать plist-файлы настроек приложений в порядке созданных профилей настроек и создавать профили Custom Settings с нуля.

Во время процесса импорта существующих профилей конфигураций утилита пробует разделить каждый словарь PayloadContent dictionary на отдельные нагрузки для профиля Workspace ONE.

Для запуска утилиты потребуется macOS 10.14 или более поздняя версия. Протестирована она была на Workspace ONE UEM 2001.

Скачать Workspace ONE Mobileconfig Importer можно по этой ссылке, а вот тут доступен документ с описанием процедуры развертывания и использования данного средства.

Одновременно с анонсом новой версии платформы виртуализации VMware vSphere 7 компания VMware объявила и о скором выпуске решения vRealize Operations 8.1, предназначенного для управления и мониторинга виртуальной инфраструктуры. Напомним, что о прошлой версии vROPs 8.0 в рамках анонсов VMworld 2019 мы писали вот тут.

Давайте посмотрим, что нового появилось в vRealize Operations 8.1:

1. Операции с интегрированной инфраструктурой vSphere и Kubernetes.

vRealize Operations 8.1 позволяет обнаруживать и мониторить кластеры Kubernetes в рамках интегрированной с vSphere инфраструктуры с возможностью автодобавления объектов Supervisor Cluster, пространств имен (Namespaces), узлов (PODs) и кластеров Tanzu Kubernetes, как только вы добавите их в vCenter, используя функции Workload Management.

После этого вам станут доступны страницы Summary для мониторинга производительности, емкости, использования ресурсов и конфигурации Kubernetes на платформе vSphere 7.0. Например, функции Capacity forecasting покажут узкие места инфраструктуры на уровне узлов, а для ежедневных операций будут полезны дашборды, отчеты, представления и алерты.

2. Операции в инфраструктуре VMware Cloud on AWS.

Теперь в облаке VMware Cloud on AWS можно использовать токен VMware Cloud Service Portal для автообнаружения датацентров SDDC и настройки средств мониторинга в несколько простых шагов. Также можно будет использовать один аккаунт для управления несколькими объектами SDDC на платформе VMware Cloud on AWS, включая сервисы vCenter, vSAN и NSX, а также будет полная интеграция с биллингом VMConAWS.

В облаке можно использовать следующие дашборды:

• Отслеживание использования ресурсов и производительность виртуальных машин, включая сервисы NSX Edge, Controller и vCenter Server.
• Мониторинг ключевых ресурсов, включая CPU, память, диск и сеть для всей инфраструктуры и виртуальных машин.
• Отслеживание трендов потребления ресурсов и прогнозирование таких метрик, как Time Remaining, Capacity Remaining и Virtual Machines Remaining.
• Нахождение виртуальных машин, которые потребляют неоправданно много ресурсов и требуют реконфигурации на базе исторических данных.

Кроме этого, для сервисов VMware NSX-T будет осуществляться полная поддержка средств визуализации и мониторинга:

Ну и в релизе vROPs 8.1 есть полная интеграция функционала отслеживания затрат VMware Cloud on AWS с решением vRealize Operations в интерфейсе портала. Это позволит контролировать уже сделанные и отложенные затраты, а также детализировать их по подпискам, потреблению и датам оплат.

Также обновился механизм обследования AWS migration assessment, который теперь позволяет сохранять несколько результатов разных сценариев для дальнейшего анализа. Эти сценарии включают в себя различные варианты параметров Reserved CPU, Reserved Memory, Fault Tolerance, Raid Level и Discounts.

3. Функции мониторинга нескольких облаков (Unified Multicloud monitoring).

Теперь средства мониторинга предоставляют еще более расширенные функции, такие как поддержка Google Cloud Platform, улучшенная поддержка AWS и новый пакет Cloud Health Management pack.

Теперь в vROPS 8.1 есть следующие сервисы GCP:

• Compute Engine Instance
• Storage Bucket
• Cloud VPN
• Big Query
• Kubernetes Engine

Пакет AWS Management Pack теперь поддерживает следующие объекты AWS Objects:

• EFS
• Elastic Beanstalk
• Direct Connect Gateway
• Target Group
• Transit Gateway
• Internet Gateway
• Elastic Network Interface (ENI)
• EKS Cluster

Пакет CloudHealth Management Pack был также улучшен, он включает в себя возможность передать данные о перспективах и ценообразовании GCP в vRealize Operations 8.1. Также вы сможете создавать любое число кастомных дэшбордов, комбинируя цены на различное соотношение ресурсов публичного, гибридного или частного облаков.

Как ожидается, vRealize Operations 8.1 выйдет в апреле этого года одновременно с релизом VMware vSphere 7. Мы обязательно напишем об этом.

Некоторое время назад мы писали о виртуальном модуле vCenter Event Broker Appliance (VEBA), который позволяет пользователям создавать сценарии автоматизации на базе событий, генерируемых в VMware vCenter Service. Например, VEBA может выполнять такие рабочие процессы, как автоматическое привязывание нужного тэга ко вновь создаваемой виртуальной машине. Работает он по модели "If This Then That".

Недавно было объявлено о выходе обновленной версии VEBA 0.3. Давайте посмотрим, что там появилось нового:

• Компонент VMware Event Router, который разделяет потоки Providers (компоненты вроде vCenter Server) и поток Processors (например, OpenFaaS). Больше об этом написано вот тут.

• Нативная поддержка AWS EventBridge в качестве Stream Processor. Это позволит пользователям VMware Cloud on AWS получить интеграцию с сервисами AWS. Более подробно можно почитать в документации.
• Поддержка всех типов событий vCenter (Event, EventEx и ExtendedEvent). В предыдущей версии VEBA поддерживалось не все множество событий, теперь же их поддерживается более чем 1600 для vSphere 6.7 Update 3, а также более 1900 для AWS 1.9. Подробнее об этом написано тут, а том, как вывести список этих событий, написано здесь.
• Теперь не нужно трансформировать тип события (например, из DrsVmPoweredOnEvent в drs.vm.powered.on). Полный список событий можно посмотреть тут.
• В файле определений stack.yaml можно подписаться на события более чем одного vCenter Server для определенной функции, например, DrsVmPoweredOnEvent или VmPoweredOffEvent.
• Доступна структура нагрузки самого vCenter.
• В структуре нагрузки VEBA теперь доступна поддержка спецификации Cloud Events.
• Упрощена схема развертывания шаблона OVF, а также появился новый комбобокс выбора Network Prefix (CIDR).

• Новый компонент statistics endpoint, который показывает использование ресурсов самого виртуального модуля VEBA, а также некоторые статистики по вызовам событий vCenter. Получить доступ к этому интерфейсу можно по адресу https://[VEBA]/stats:

• Обновленные примеры функций:
  • Все существующие примеры функций  были обновлены, чтобы отразить поддержку VEBA v0.3.
  • Официальные Docker-образы VMware теперь построены для примеров функций и не ссылаются на отдельные аккаунты. Все образы поддерживаются со стороны сообщества разработчиков.
  • Новая функция "echo" для Python, которая позволяет посмотреть как рабочая нагрузка будет видна с сервера vCenter.
  • Новая функция оповещения по почте о датасторах vSphere, которую очень хотели пользователи VMware Cloud on AWS.

Скачать VMware vCenter Event Broker Appliance 0.3 можно по этой ссылке.

На днях компания VMware сделала много важных анонсов, о двух из них мы уже рассказали:

• Анонсирована новая версия VMware vSphere 7 - что нового?
• Анонсирована новая версия VMware vSAN 7.0 - что там будет интересного?

Одновременно с этим было объявлено и о скором выпуске обновленной версии решения VMware Site Recovery Manager 8.3, предназначенного для обеспечения катастрофоустойчивости виртуальных датацентров. Напомним, что о прошлой версии SRM 8.2 мы писали в мае прошлого года. Главной новой возможностью тогда стала реализация функций продукта в виртуальном модуле (Virtual Appliance) на базе Photon OS.

Давайте посмотрим, что нового появилось в SRM 8.3:

1. Интеграция с Virtual Volumes (vVols).

Это было одной из самых ожидаемых возможностей SRM. Теперь тома vVols полностью поддерживаются для защиты с помощью SRM на базе технологий репликации на уровне дискового массива. Репликация для томов vVols работает на уровне отдельных виртуальных машин, а также в составе групп (replication groups).

Как некоторые знают, компонент VASA provider заменил модуль SRA (Storage Replication Adaptor), поэтому ежедневные операции теперь выполняются проще и быстрее. Сначала поддержка будет реализована для хранилищ Pure, HPE 3par и Nimble, но вскоре появится и для других вендоров. Список совместимости доступен здесь и будет постоянно обновляться.

2. Автоматическая защита виртуальных машин.

Раньше если вам было необходимо добавить ВМ в защищаемые на protected datastore, нужно было открыть консоль SRM и добавить ее в protection group. Теперь же, если машина перемещается на такой датастор с помощью vMotion или создается там администратором, то она автоматически попадает в состав защищенной группы.

Точно такая же автоматическая защита теперь распространяется и на тома vVols, которые поддерживаются, начиная с этой версии SRM.

Надо отметить, что если машина перемещается между датасторами через Storage vMotion, то она не попадает в protection group. Это сделано для того, чтобы предотвратить изменение protection group для машины во время этой операции.

3. Бесшовное изменение размера диска.

Раньше для изменения размера диска реплицируемой машины средствами vSphere Replication требовалось сделать несколько ручных операций на стороне таргета репликации. Теперь же эта операция делается автоматически, когда вы меняете размер диска исходной ВМ.

4. Утилита vSphere Replication Configuration Export/Import Tool.

В SRM 8.1 появилась возможность сохранять и восстанавливать конфигурацию защищаемой среды, а в SRM 8.3 с помощью утилиты vSphere Replication Configuration Export/Import Tool можно делать то же самое для конфигураций репликации. Теперь администраторы могут сделать резервную копию конфигураций реплицируемых ВМ, включая RPO, MPIT, компрессии, подморозки (quiescing), шифрования, настройки датасторов и все прочее. Пока эта возможность доступна только через CLI.

5. Улучшения интерфейса.

В плане UI в SRM 8.3 было сделано очень много изменений, вот лишь некоторые из них:

• Улучшения репортинга, включая возможность экспорта всех представлений в формат CSV.
• Пользователь теперь может экспортировать детали репликации отдельных ВМ.
• Интерфейс репликации теперь включает статистику lag time, которая показывает прошедшее с момента последней репликации время.
• Возможность спрятать/показать колонки во всех табличных представлениях.
• Список replications list теперь показывает ассоциированные protection groups.

6. Улучшения производительности vSphere Replication.

Инженеры VMware приложили много усилий для внесения оптимизаций в эту версию vSphere Replication. Улучшения касаются как механизма первоначальной синхронизации, так и постоянной репликации машины под нагрузкой.

7. Прочие улучшения.

• Улучшения утилиты SRM Configuration Import/Export Tool.
• Расширенные возможности плагинов vRO для SRM и vSphere Replication, включая рабочие процессы для томов vVols.
• Новые возможности для vROps Management packs, как для SRM, так и для vSphere Replication.
• Улучшенная интеграция с хранилищами vSAN, которые теперь больше понимают о наличии данных реплик vSphere Replication.
• Улучшения безопасности, включая поддержку FIPS в интерфейсе, и интеграция с шифрованием vSphere Trust Authority.

Доступность для загрузки VMware Site Recovery Manager 8.3 ожидается в апреле, одновременно с релизами vSphere 7 и vSAN 7. Пока за обновлениями можно следить на этой странице.

На днях компания VMware объявила о скором выпуске платформы виртуализации VMware vSphere 7.0, где будет много интересных новых возможностей. Одновременно с этим было объявлено и о будущем релизе новой версии VMware vSAN 7.0 - решения для организации отказоустойчивых хранилищ для виртуальных машин на базе локальных хранилищ хост-серверов VMware ESXi.

Давайте посмотрим, что интересного было анонсировано в новой версии решения VMware vSAN 7:

1. Интеграция с vSphere Lifecycle Manager (vLCM) для обновления кластеров

Ранее администраторы vSphere использовали Update Manager (VUM) для обновлений платформы и драйверов, а утилиты от производителей серверов для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager:

vLCM можно использовать для применения установочных образов, отслеживания соответствия (compliance) и приведения кластера к нужному уровню обновлений. Это упрощает мониторинг инфраструктуры на предмет своевременных обновлений и соответствия компонентов руководству VMware Compatibility Guide (VCG) за счет централизованного подхода на уровне всего кластера.

2. Службы Native File Services for vSAN

С помощью служб Native File Services кластер vSAN теперь поддерживает управление внешними хранилищами NFS v3 и v4.1. Это позволяет использовать их совместно с другими возможностями, такими как службы iSCSI, шифрование, дедупликация и компрессия. Теперь через интерфейс vCenter можно управлять всем жизненным циклом хранилищ на базе разных технологий и превратить его в средство контроля над всей инфраструктурой хранения.

3. Развертывание приложений с использованием Enhanced Cloud Native Storage

Напомним, что функции Cloud Native Storage появились еще VMware vSAN 6.7 Update 3. Cloud Native Storage (CNS) - это функциональность VMware vSphere и платформы оркестрации Kubernetes (K8s), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.

Теперь эти функции получили еще большее развитие. Тома persistent volumes могут поддерживать шифрование и снапшоты. Также полностью поддерживается vSphere Add-on for Kubernetes (он же Project Pacific), который позволяет контейнеризованным приложениям быть развернутыми в кластерах хранилищ vSAN.

4. Прочие улучшения

Тут появилось довольно много нового:

• Integrated DRS awareness of Stretched Cluster configurations. Теперь DRS отслеживает, что виртуальная машина находится на одном сайте во время процесса полной синхронизации между площадками. По окончании процесса DRS перемещает машину на нужный сайт в соответствии с правилами.
• Immediate repair operation after a vSAN Witness Host is replaced. Теперь процедура замены компонента Witness, обеспечивающего защиту от разделения распределенного кластера на уровне площадок, значительно упростилась. В интерфейсе vCenter есть кнопка "Replace Witness", с помощью которой можно запустить процедуру восстановления конфигурации и замены данного компонента.
• Stretched Cluster I/O redirect based on an imbalance of capacity across sites. В растянутых кластерах vSAN можно настраивать защиту от сбоев на уровне отдельных ВМ за счет выделения избыточной емкости в кластере. В результате на разных площадках могут оказаться разные настройки, и появится дисбаланс по доступной емкости и нагрузке по вводу-выводу. vSAN 7 позволяет перенаправить поток ввода-вывода на менее загруженную площадку прозрачно для виртуальных машин.
• Accurate VM level space reporting across vCenter UI for vSAN powered VMs. Теперь в vSAN 7 есть возможности точной отчетности о состоянии хранилищ для виртуальных машин, точно так же, как и для остальных хранилищ в представлениях Cluster View и Host View.
• Improved Memory reporting for ongoing optimization. Теперь в интерфейсе и через API доступна новая метрика потребления памяти во времени. Она позволяет понять, как меняется потребление памяти при изменениях в кластере (добавление и удаление хостов, изменение конфигурации).
• Visibility of vSphere Replication objects in vSAN capacity views. vSAN 7 позволяет администраторам идентифицировать объекты vSphere Replication на уровне виртуальных машин и кластеров, что упрощает управление ресурсами для нужд репликации.
• Support for larger capacity devices. Теперь vSAN 7 поддерживает новые устройства хранения большой емкости и плотности носителей.
• Native support for planned and unplanned maintenance with NVMe hotplug. Для устройств NVMe теперь доступна функция горячего добавления и удаления, что позволяет сократить время и упростить процедуру обслуживания.
• Removal of Eager Zero Thick (EZT) requirement for shared disk in vSAN. Теперь общие диски в vSAN не требуется создавать в формате EZT, что ускоряет развертывание в кластере vSAN нагрузок, таких как, например, Oracle RAC.

Больше информации о новых возможностях можно почитать в даташите о vSAN 7. Ну а технические документы будут постепенно появляться на StorageHub. Как и VMware vSphere 7, планируется, что решение vSAN 7 выйдет в апреле этого года.

На днях, как вы знаете, было много интересных новостей. И вот еще одна - компания VMware анонсировала большое обновление своей флагманской платформы виртуализации VMware vSphere 7. Напомним, что прошлая мажорная версия этого решения VMware vSphere 6.7 вышла весной 2018 года.

Сразу скажем, что это лишь анонс, а не объявление о доступности новой версии продукта для скачивания - как правило, GA версия vSphere появляется в течение месяца после анонса. Поэтому будем пока ожидать VMware vSphere 7 в апреле, а сегодня расскажем о новых возможностях этой платформы.

1. Улучшения сервисов VMware vCenter

Здесь можно отметить упрощение топологии vCenter Server SSO:

• Возможность апгрейда vCenter Server для пользователей с внешним PSC на консолидированную топологию на базе одного сервера vCSA.
• Embedded PSC теперь единственно возможный вариант развертывания. Внешний PSC больше не поддерживается.

Профили vCenter Server Profiles:

• Эта новая возможность для серверов vCenter работает точно так же, как Host Profiles работает для хостов. Теперь вы можете сравнивать и экспортировать настройки серверов vCenter в формате JSON для целей резервного копирования или применения этих настроек к другому серверу vCenter через REST API.

Функции vCenter Multi-Homing:

• Теперь для управляющего трафика vCSA можно использовать до 4 адаптеров vNIC, среди которых один vNIC зарезервирован для механизма vCHA.

Улучшения Content Library

• Теперь появилось новое представление для управления шаблонами, в котором доступны функции Check-In и Check-Out для управления версиями шаблонов и возможностью откатиться к предыдущей версии.
• Сначала делается Check-Out для открытия возможности внесения изменений, потом можно сделать Check-In для сохранения изменений в библиотеке.

Новая функция vCenter Server Update Planner:

• Новая возможность доступна как часть vSphere Lifecycle Manager (vLCM) для серверов vCenter.
• С помощью планировщика обновлений можно получать оповещения об обновлениях vCenter, планировать апгрейды, накатывать их, а также проводить анализ "что если" перед проведением обновления.
• Возможность выполнения pre-upgrade проверок для выбранного сервера vCenter.

2 Улучшения механизма VMware DRS

• Теперь DRS запускается каждую минуту, а не каждые 5 минут, как раньше.
• Для генерации рекомендаций используется механизм VM DRS score (он же VM Hapiness).
• Теперь это Workload centric механизм - это означает, что теперь в первую очередь учитываются потребности самой виртуальной машины и приложения в ней, а только потом использование ресурсов хоста.
• Расчеты по памяти основываются на granted memory вместо стандартного отклонения по кластеру.
• Появился механизм Scaleable Shares, который позволяет лучше выделать Shares в пуле ресурсов с точки зрения их балансировки.

3. Улучшения vMotion

Тут появились такие улучшения:

• Улучшения миграций для Monster VM (с большими ресурсами и очень высокой нагрузкой), что позволяет увеличить шанс успешной миграции.
• Использование только одного vCPU при отслеживании изменившихся страниц (page tracer) вместо всех vCPU, что меньше влияет на производительность во время миграции.
• Уменьшение времени переключения контекста на другой сервер (теперь меньше одной секунды). Достигается за счет переключения в тот момент, когда compacted memory bitmap уже передана на целевой сервер, вместо ожидания передачи full bitmap.

4. Новые функции vSphere Lifecycle Manager (vLCM)

Здесь можно отметить 2 улучшения:

• Функция Cluster Image Management, которая включает обновления firmware, драйверов и образов ESXi разных версий.
• Первоначальная поддержка решений Dell OpenManage и HP OneView.

5. Возможности Application Acceleration (Tech Preview)

Эти функции пришли от приобретенной компании Bitfusion. Они позволяют оптимизировать использование GPU в пуле по сети, когда vGPU может быть частично расшарен между несколькими ВМ. Это может использоваться для рабочих нагрузок задач приложений AI/ML.

Все это позволяет организовать вычисления таким образом, что хосты ESXi с аппаратными модулями GPU выполняют виртуальные машины, а их ВМ-компаньоны на обычных серверах ESXi исполняют непосредственно приложения. При этом CUDA-инструкции от клиентских ВМ передаются серверным по сети. Подробнее можно почитать у нас тут.

6. Функции Assignable Hardware

Эта возможность позволяет использовать так называемый Dynamic DirectPath I/O для машин, которым требуется работа с устройствами PCIe passthrough и Nvidia GRID. Теперь с его помощью можно подобрать хосты с определенными требованиями к аппаратным компонентам, такими как vGPU и PCIe. Это позволяет, в свою очередь, использовать для таких ВМ технологии HA и DRS Initial Placement в кластере, где есть совместимые по оборудованию хосты ESXi.

7. Управление сертификатами

Здесь 2 основных новых возможности:

• Новый мастер импорта сертификатов.
• Certificate API для управления сертификатами с помощью сценариев.

8. Возможности Identity Federation

Функции ADFS теперь поддерживаются из коробки, также будет поддерживаться больше IDP, использующих механизмы OAUTH2 и OIDC.

9. Функции vSphere Trust Authority (vTA)

• vTA использует отдельный кластер хостов ESXi, чтобы создать отдельный аппаратный узел доверия.
• Этот кластер сможет зашифровывать вычислительный кластер и его ВМ вместе с vCenter и другими управляющими компонентами.
• Можно использовать механизм аттестации, когда требуются ключи шифрования.
• Теперь проще добиться соблюдения принципа наименьших привилегий, а также расширить пространство аудита.

10. Возможность vSGX / Secures Enclaves (Intel)

• Расширения Intel Software Guard Extensions (SGX) позволяют переместить чувствительную логику и хранилище приложения в защищенную область, к которой не имеют доступа гостевые ОС и гипервизор ESXi.
• Возможности SGX исключают использование vMotion, снапшотов, Fault Tolerance и других технологий. Поэтому SGX лучше использовать только тогда, когда по-другому нельзя.

11. Новое издание vSphere with Kubernetes (Project Pacific)

О Project Pacific мы подробно рассказывали вот тут. Он представляет собой набор средств для преобразования среды VMware vSphere в нативную платформу для кластеров Kubernetes. vCenter Server предоставляет возможности по управлению кластерами k8s (любые кластеры старше n-2 будут обновлены). Также в решение интегрирован Harbor, который может быть включен для каждого пространства имен.

Доступно это пока только для пользователей VMware Cloud Foundation (4.0), так как решение завязано на компонент VMware NSX-T.

12. Улучшения VMware Tools

Функции Guest Store теперь доступны в гостевой ОС (такие как обновление VMware Tools из гостевой ОС).

13. Обновленное железо (VM Hardware v17)

Тут основные улучшения таковы:

• Virtual Watchdog Timer - теперь нет зависимости от физического железа для рестарта ВМ в случае, если гостевая ОС не отвечает.
• Precision Time Protocol (PTP) - для приложений очень чувствительных ко времени (например, торговые платформы для трейдеров) можно использовать PTP вместо NTP и назначать его использование для виртуальных машин.

14. Улучшения vSphere Client

Здесь появились следующие улучшения:

• Начала сохраняться история поиска.
• В API Explorer теперь лучше видны все доступные API.
• Для Code Capture появилась возможность выбора языка сценариев - PowerCLI, Javascript, Python или Go.

Конечно же, это далеко не все новые возможности VMware vSphere 7, представленные на днях. В ближайшее время мы расскажем еще много нового о них, а кроме того, посмотрим также и на анонсированные решения семейства VMware Tanzu, VMware Cloud Foundation 4 и vRealize 8.1.

В блоге VMware vSphere появилась интересная запись о том, как происходит работа с памятью в гипервизоре VMware ESXi. Приведем ее основные моменты ниже.

Работа виртуальной машины и ее приложений с памятью (RAM) идет через виртуальную память (Virtual Memory), которая транслируется в физическую память сервера (Physical Memory). Память разбита на страницы - это такие блоки, которыми виртуальная память отображается на физическую. Размер этого блока у разных систем бывает разный, но для ESXi стандартный размер страниц равен 4 КБ, а больших страниц - 2 МБ.

Для трансляции виртуальных адресов в физические используется таблица страниц (Page Table), содержащая записи PTE (Page Table Entries):

Записи PTE хранят в себе ссылки на реальные физические адреса и некоторые параметры страницы памяти (подробнее можно почитать здесь). Структуры записей PTE могут быть разного размера - это WORD (16 bits/2 bytes), DWORD (32 bits/4 bytes) и QWORD (64 bits/8 bytes). Они адресуют большие блоки адресов в физической памяти, к примеру, DWORD адресует блок адресов 4 килобайта (например, адреса от 4096 до 8191).

Память читается и передается гостевой системе и приложениям страницами по 4 КБ или 2 МБ - это позволяет читать содержимое ячеек памяти блоками, что существенно ускоряет быстродействие. Естественно, что при таком подходе есть фрагментация памяти - редко когда требуется записать целое число страниц, и часть памяти остается неиспользуемой. При увеличении размера страницы растет и их фрагментация, но увеличивается быстродействие.

Таблицы страниц (а их может быть несколько) управляются программным или аппаратным компонентом Memory Management Unit (MMU). В случае аппаратного MMU гипервизор передает функции по управлению трансляцией ему, а программный MMU реализован на уровне VMM (Virtual Machine Monitor, часть гипервизора ESXi):

Важный компонент MMU - это буфер ассоциативной трансляции (Translation Lookaside Buffer, TLB), который представляет собой кэш для MMU. TLB всегда находится как минимум в физической памяти, а для процессоров он часто реализован на уровне самого CPU, чтобы обращение к нему было максимально быстрым. Поэтому обычно время доступа к TLB на процессоре составляет около 10 наносекунд, в то время, как доступ к физической памяти составляет примерно 100 наносекунд. VMware vSphere поддерживает Hardware MMU Offload, то есть передачу функций управления памятью на сторону MMU физического процессора.

Итак, если от виртуальной машины появился запрос на доступ к виртуальному адресу 0x00004105, то этот адрес разбивается на адрес виртуальной страницы (Virtual page number - 0x0004) и смещение (Offset - 0x105 - область внутри страницы, к которой идет обращение):

Смещение напрямую передается при доступе к физической странице памяти, а вот тэг виртуальной страницы ищется в TLB. В данном случае в TLB есть запись, что соответствующий этому тэгу адрес физической страницы это 0x0007, соответственно трансляция виртуальной страницы в физическую прошла успешно. Это называется TLB Hit, то есть попадание в кэш.

Возможна и другая ситуация - при декомпозиции виртуального адреса получаемый тэг 0x0003 отсутствует в TLB. В этом случае происходит поиск страницы в физической памяти по тэгу (страницу номер 3) и уже ее адрес транслируется (0x006). Далее запись с этим тэгом добавляется в TLB (при этом старые записи из кэша вытесняются, если он заполнен):

Надо отметить, что такая операция вызывает несколько большую задержку (так как приходится искать в глобальной памяти), и такая ситуация называется TLB Miss, то есть промах TLB.

Но это не самая плохая ситуация, так как счет latency все равно идет на наносекунды. Но доступ может быть и гораздо более долгий (миллисекунды и даже секунды) в том случае, если нужная гостевой ОС страница засвопировалась на диск.

Посмотрим на пример:

Виртуальная машина обратилась к виртуальному адресу 0x00000460, для которого есть тэг 0x0000. В физической памяти для этого тэга выделена страница 0, которая означает, что искать эту страницу нужно на диске, куда страница была сброшена ввиду недостатка физической оперативной памяти.

В этом случае страница восстанавливается с диска в оперативную память (вытесняя самую старую по времени обращения страницу), ну и далее происходит трансляция адреса к этой странице. Эта ситуация называется отказ страницы (Page Fault), что приводит к задержкам в операциях приложения, поэтому иногда полезно отслеживать Page Faults отдельных процессов, чтобы понимать причину падения быстродействия при работе с памятью.

Как некоторые из вас помнят, компания VMware в 2018 году анонсировала специальное издание vSphere Platinum, которое вышло одновременно с обновлением vSphere 6.7 Update 1. Решение vSphere Platinum стало комбинацией из двух продуктов: платформы VMware vSphere Enterprise Plus и решения VMware AppDefense. Помимо этого, в рамках издания Platinum был достпен специальный плагин для vSphere Client, который реализовывал интеграцию vSphere и AppDefense (называется он vCenter Server plugin for vSphere Platinum).

В целом, решение vSphere Platinum особо нигде не обсуждалось, и, как стало теперь понятно, никем особенно не покупалось. Поэтому VMware решила снять его с производства (End of Availability), начиная со 2 апреля 2020 года. Одновременно с vSphere Platinum в прошлое с этой даты уходят и решения VMware Cloud Foundation Platinum и VMware vCloud Suite Platinum. Компоненты решений продолжат поддерживаться в соответствии с VMware Lifecycle Product Matrix.

Существующие пользователи vSphere Platinum после объявленной даты получат лицензии vSphere Enterprise Plus, SaaS-продукт VMware AppDefense и плагин VMware AppDefense Plugin for vSphere (о том, где скачать этот плагин написано вот тут). Для пользователей vCloud Suite Platinum и Cloud Foundation Platinum ничего не меняется, за исключением эволюции самой vSphere, входящей в состав пакетов.

На сайте VMware Labs очередное обновление - обновился пакет vRealize Build Tools до версии 2.4.18. С помощью данного средства разработчики и администраторы, работая совместно, могут реализовать новые сценарии и рабочие процессы vRealize Automation и vRealize Orchestrator, используя стандартные практики DevOps. Напомним, что о прошлой версии этого решения мы писали вот тут.

Пакет сфокусирован на качестве кода, его повторном использовании, модульном тестировании, управлении взаимосвязями и параллельных релизах проектов под платформу vRealize. vRealize Build Tools представляют собой расширения (extensions), упакованные в формат репозитория Maven, которые поддерживают использование IDE (через Maven), а также интерфейса CLI для разработки, тестирования и развертывания решений для платформ vRA/vRO.

Давайте посмотрим что нового появилось во второй версии:

• Поддержка решения vRA 8, его блупринтов (blueprints), кастомных форм, подписок и механик flavor-mapping
• Поддержка существующего контента и импорт его для vRO 8
• Поддержка функций vRO 8 по экспорту рабочих процессов в структуру папок, созданную на базе их тэгов
• Запуск рабочих процессов на vRO с использованием команды maven
• Возможность сохранения JS Actions IDs на источнике в целях предотвращения конфликтов в среде vRO
• Улучшения экспериментальной поддержки проектов TypeScript
• Исправления ошибок и обновление документации

Для начала работы с vRealize Build Tools вам понадобятся следующие инструменты:

• vRealize Orchestrator
• Microsoft VS Code
• vRealize Developer Tools

Скачать vRealize Build Tools можно по этой ссылке.

В конце января мы писали о средстве Power vRA Cloud, которое позволяет отобразить сложное множество программных интерфейсов VMware vRealize Automation Cloud API в простой набор функций PowerShell. На днях вышло обновление этого PowerShell-модуля - Power vRA Cloud 1.1.

Помимо множества исправлений ошибок, в утилите появилось несколько новых командлетов:

• Add-vRA-Project-Administrator
• Add-vRA-Project-Member
• Get-vRA-DeploymentFilters
• Get-vRA-DeploymentFilterTypes
• Get-vRA-FabricNetworksFilter
• Get-vRA-FabricImagesFilter
• Remove-vRA-Project-Administrator
• Remove-vRA-Project-Member
• Update-vRA-Project-ZoneConfig

Напомним, что этот модуль не поддерживается со стороны VMware (как и все утилиты на VMware Labs, находящиеся в статусе Tech Preview), поэтому используйте его осторожно.

Скачать Power vRA Cloud можно по этой ссылке. Документация по использованию данного средства скачивается вместе с самим модулем.

В последнее время VMware уделяет очень много внимания средствам для работы с кластерами Kubernetes (например, посмотрите нашу статью про решения Tanzu Mission Control и Project Pacific). Как оказалось, у VMware постоянно обновляется специальная утилита Weathervane 2.0, которая позволяет производить тестирование производительности кластеров Kubernetes под нагрузкой. Напомним, что о первой версии этой утилиты мы писали два с половиной года назад.

Это средство может оказаться вам полезным в следующих случаях:

• Когда нужно сравнить два кластера по производительности (например, на разном оборудовании)
• Когда нужно понять влияние изменений конфигурации кластера на производительность
• Когда нужно проверить корректность настройки нового кластера перед запуском его в производственную среду

Для запуска Weathervane вам нужно создать образы контейнеров, подготовить конфигурационный файл и запустить бенчмарк. Далее утилита сама развернет контейнеры в кластере, запустит приложения и соберет результаты тестирования.

Weathervane деплоит бенчмарк-приложение на узлах и подает туда нагрузку, которая генерируется через компонент Workload driver. Этот драйвер может располагаться как вместе с бенчмарк-приложением, так и во внешней среде, в отдельном кластере.

Weathervane можно установить на постоянную нагрузку для фиксированного числа симулируемых пользователей, а можно настроить на поиск максимального числа пользователей таким образом, чтобы выполнялись требования quality-of-service (QoS). В последнем случае результатом теста будет максимальное число WvUsers, которое способен выдержать кластер. Собственно, этот параметр и нужно использовать для сравнения кластеров по производительности.

Вот как выглядят компоненты решения Weathervane (компонент Run harness отвечает за исполнение тестовых прогонов и получение результатов тестирования):

Weathervane использует многоярусное веб-приложение, которое включает в себя stateless и stateful сервисы. Вы можете выбрать один из этих типов развертывания приложений. Несколько экземпляров приложений можно запускать в рамках одного прогона, что позволяет масштабировать тестирование в больших кластерах.

Приложение Weathervane состоит из нескольких ярусов. Логика приложения реализована через Java-сервисы, запущенные на сервере Tomcat, которые коммуницируют через REST API и сообщения RabbitMQ, а Zookeeper используют для координации. Бэкенд-хранилища реализованы средствами PostgreSQL и Cassandra. Фронтенд веб-серверы и прокси-кэш серверы реализованы на Nginx.

Недавно VMware провела тестирование кластеров с помощью Weathervane 2 для двух сценариев. В первом случае коллеги сравнили производительность двух поколений серверов:

Результат для различного числа микроинстансов приложений получился таким:

Как видно из картинки, если судить по числу WvUsers, то новое железо выиграло у старого в два раза (там и ядер в процессорах больше в 2 раза, но работают они на меньшей частоте). А на эквивалентном числе пользователей производительность кластера на новом оборудовании была на 15-29% выше.

Второй тест делался на разных сетевых конфигурациях кластеров Kubernetes, которые масштабировались до 16 экземпляров приложений. В первом случае использовалась механика Flannel/VXLAN, а во втором - Flannel/host-gw, которая и выиграла у первой примерно на 10%:

Скачать утилиту VMware Weathervane 2.0 можно из репозитория на GitHub по этой ссылке.

Cody Hosterman, известный своими заметками про PowerCLI, написал интересную статью о том, как запоминать дефолтные параметры на примере свойств соединения с дисковым массивом. Это может вам оказаться полезным, например, в случае если вы работаете с дисковым массивом в интерактивном режиме, при этом не хотите каждый раз указывать параметры соединения.

К примеру, при использовании модуля PureStorage.FlashArray.VMware есть возможность передавать параметры соединения, сохраненные в глобальной переменной $Global:DefaultFlashArray. Неудобство этого метода в том, что каждый раз вы должны указывать параметр -Array:

Поэтому в PowerCLI заложен отличный механизм дефолтных параметров для нужных вам командлетов. Например, можно создать переменную с параметрами соединения с массивом:

$flasharray = new-pfaarray -endpoint 10.21.202.60 -credentials (get-credential) -ignoreCertificateError

Далее можно записать эту переменную в дефолтные параметры:

$PSDefaultParameterValues = @{
 "*-pfa*:Array"=$flashArray;

  }

Это позволит для параметра, называющегося Array применять параметры соединения из переменной $flashArray. При этом эти параметры будут применяться только для командлетов, содержащих "-pfa" в своем названии (они есть только в модуле PureStoragePowerShellSDK).

Для всего модуля и всех командлетов нет простого способа задать дефолтные параметры, но можно получить в сценарии список всех доступных командлетов и для всех них прописать правило использования параметра -Array:

$psCMDs = (get-command -Module PureStoragePowerShellSDK).Name

  $defaultParamHash = @{}

  foreach ($psCMD in $psCMDs)

  {

$defaultParamHash.Add("$($psCMD):Array",$flashArray)

}

$PSDefaultParameterValues = $defaultParamHash

После этого вы сможете просто использовать командлеты без параметров, например, Get-PfaVolumes, чтобы получить все тома с заданного в дефолтном соединении массива:

Аналогично способ будет работать и для всех остальных параметров командлетов и любых других модулей.

Как вы знаете, каждый год VMware раздает награды VMware vExpert тем, кто вносит вклад в развитие сообщества, собранного вокруг технологий виртуализации. Звание это присуждается уже довольно давно, его носителей стало так много, что появилась даже уже более узкая подкатегория vExpert Pro.

В России тоже набралось уже 10 человек носителей vExpert, не так много, но и не мало (на уровне Швеции и Норвегии). Понятное дело, что большинство vExpert из тех стран, где все хорошо с английским, так как аудитория блогов на английском языке шире, что мотивирует авторов писать посты (а в целом vExpert дают за ведение блога).

Вот так выглядит первая десятка:

А вот те специалисты из России, кто получил vExpert в этом году:

Полный список получателей vExpert опубликован тут.

Многие пользователи платформы VMware vSphere знают, что есть такой вариант развертывания и эксплуатации распределенной виртуальной инфраструктуры как ROBO (Remote or Brunch Offices). Она подразумевает наличие одного или нескольких главных датацентров, откуда производится управление небольшими удаленными офисами, где размещено несколько серверов VMware ESXi под управлением собственного vCenter или без него.

В конце прошлого года компания VMware выпустила интересный документ "Performance of VMware vCenter Server 6.7 in Remote Offices and Branch Offices" (мы уже немного рассказывали о нем тут), где рассматривается главный аспект применения такого сценария - производительность. Ведь удаленные офисы могут располагаться в других городах, странах и даже континентах, доступ к которым осуществляется по разным типам соединений (например, 4G или спутник), поэтому очень важно, сколько трафика потребляют различные операции, и как быстро они отрабатывают с точки зрения администратора.

Параметры различных типов сетевых соединений в VMware свели в табличку (в правой колонке, что получалось в результате использования тестовой конфигурации, а в левой - как бывает в сценариях с реальными датацентрами):

Для тестирования использовалась удаленная конфигурация из 128 хостов ESXi, где было зарегистрировано 3840 виртуальных машин (960 ВМ на кластер, 30 на хост), из которых включалось до 3000 машин одновременно.

Сначала посмотрим на фоновый трафик для синхронизации хостов ESXi и vCenter, в зависимости от числа виртуальных машин на хосте (трафик в сторону vCenter):

Теперь посмотрим на трафик в обратную сторону (там просто передаются команды к хостам, ВМ не сильно затрагиваются, поэтому отличия небольшие):

Теперь посмотрим на то, как отличается объем передаваемого трафика от ESXi к vCenrer в зависимости от уровня собираемой статистики на сервере VMware vCenter:

Теперь давайте посмотрим, как отличается трафик к vCenter в зависимости от числа включенных виртуальных машин на хосте:

Посмотрим на трафик в обратную сторону (от vCenter к хостам ESXi) в зависимости от уровня статистики:

Теперь интересно посмотреть, сколько операций в минуту может выполнять vCenter с удаленными серверами ESXi в зависимости от типа соединения, а также задержки в секундах при выполнении операций:

Теперь посмотрим на задержки при выполнении отдельных операций, в зависимости от типа соединения:

Авторы документа отмечают, что больше всего на производительность операций vCenter влияет не полоса пропускания, а latency между сервером vCenter (который может быть в головном офисе) и хостами ESXi (которые могут быть на удаленной площадке).

Теперь посмотрим на сетевой трафик от хоста ESXi к серверу vCenter, который включает в себя фоновый трафик, а также собираемую статистику Level-1:

Посмотрим на такой трафик в обратную сторону - от ESXi к vCenter:

Ну а теперь посмотрим задержки на выполнение операций уже с хостами ESXi, а не с виртуальными машинами:

И в заключение, посмотрим на трафик от хостов ESXi к серверу vCenter при выполнении операций с хостами:

В общем, очень интересный документ - будет не лишним прочитать его полностью.

Как знают многие администраторы, во время установки vCenter Server Appliance (vCSA) для управления виртуальной инфраструктурой изменить MAC-адрес управляющего сервера нельзя - он генерируется при развертывании виртуального модуля установщиком и прописывается внутрь конфигурации. Между тем, если вам это все-таки по каким-то причинам требуется, Вильям Лам привел способ, как это сделать.

Ниже приведена процедура развертывания vCSA с сервера VMware ESXi.

Во-первых, надо преобразовать OVA-модуль в формат OVF, где можно будет потом изменить настройки. Делается это с помощью утилиты ovftool следующим образом:

ovftool --allowExtraConfig VMware-vCenter-Server-Appliance-6.7.0.42000-15132721_OVF10.ova VMware-vCenter-Server-Appliance-6.7.0.42000-15132721_OVF10.ovf

Сначала нам нужно добавить следующую конфигурацию в раздел Network конфигурации виртуального модуля OVF, содержащую нужный нам MAC-адрес:

<Item>

   <rasd:Address>00:50:56:ab:cd:ef</rasd:Address>

   <rasd:AutomaticAllocation>true</rasd:AutomaticAllocation>

   <rasd:Connection>Network 1</rasd:Connection>

   <rasd:ElementName xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData">Ethernet adapter on &quot;Network 1&quot;</rasd:ElementName>
   <rasd:InstanceID xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData">3</rasd:InstanceID>

   <rasd:ResourceSubType>vmxnet3</rasd:ResourceSubType>

   <rasd:ResourceType>10</rasd:ResourceType>

</Item>

Далее изменяем скрипт VCSAStaticMACAddress.sh на сервере ESXi, чтобы добавить туда нужные параметры вашего vCSA и начать его развертывание в вашей виртуальной среде. Для этого его нужно выполнить с параметром --injectOvfEnv, про который написано вот тут. Он позволяет внедрить свойства OVF в виртуальный модуль vCSA при его включении.

Если вы все сделали правильно, то сможете наблюдать за прогрессом развертывания вашего виртуального модуля из браузера по ссылке:

https://[адрес VCSA]:5480

В итоге вы должны увидеть, что в настройках модуля vCSA вы получили нужный вам MAC-адрес:

Если вы хотите пропустить стадию конфигурации сетевых настроек (IP-адрес и прочее) при исполнении скрипта, нужно выставить переменную VCSA_STAGE1ANDSTAGE2 в значение false. Тогда после развертывания модуля vCSA нужно будет закончить его конфигурацию по ссылке:

https://[адрес VCSA]:5480

После развертывания эта возможность будет доступна на открывшейся странице:

На сайте проекта VMware Labs обновилось средство App Volumes Entitlement Sync до версии 2.3. Это решение позволяет прочитать, сравнить и синхронизировать права доступа к объектам между экземплярами App Volumes на географически разделенных площадках. После аутентификации на обеих площадках вы сможете выбрать права доступа, которые надо сравнить или синхронизировать.

Напомним, что о версии App Volumes Entitlement Sync 2.2 мы писали вот тут, давайте посмотрим, что нового появилось в версии 2.3:

• Исправлена периодически возникающая ошибка "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel"
• Если AppStacks на источнике и назначении не совпадают, показывается соответствующее сообщение
• В списке назначений показывается префикс монтирования
• Версия App Volumes 4.0 пока не поддерживается, ее поддержка будет добавлена в следующей версии

Скачать VMware App Volumes Entitlement Sync 2.3 можно по этой ссылке.

На сайте проекта VMware Labs появилась обновленная версия веб-клиента для управления платформой VMware vSphere - HTML5 Web Client 5.0 (он же vSphere Client в релизной редакции vSphere). Напомним, что прошлая версия vSphere Client 4.3 вышла еще в сентябре прошлого года.

Давайте посмотрим, что нового появилось в основном клиенте vSphere, функции которого будут включены в очередной крупный апдейт платформы:

• Новый язык для механизма Code Capture - теперь запись происходящего в интерфейсе может быть транслирована в код на языке Go.
• Операционная система виртуального модуля клиента заменена на Photon OS. Соответственно, обновления на версию 5.0 с более ранних версий не поддерживаются.
• Функция PowerActions - теперь PowerCLI и vSphere Client будут плотно интегрированы (см. раздел Developer Center). Это позволяет исполнять сценарии PowerCLI прямо из vSphere Client, а также сохранять их в библиотеке. Кастомные действия, которые записаны как PowerCLI-сценарии, теперь можно выполнять для заданных объектов из инвентори.
• Чтобы PowerActions заработали, нужно их явно включить во время развертывания виртуального модуля vSphere Client. Для того, чтобы узнать больше об этом механизме, прочитайте документ PowerActions_documentation_Fling50.pdf из состава дистрибутива.

Скачать VMware vSphere Client 5.0 можно по этой ссылке. Там же, выбрав из комбо-бокса, можно загрузить и всю необходимую документацию.

Интересная штука появилась на GitHub - проект VMware Community Homelabs от Вильяма Лама, в котором описаны конфигурации и стоимость аппаратных тестовых лабораторий участников комьюнити VMware, которые они строят у себя дома или где-либо еще за свои деньги.

Самая бюджетная (кстати, у Вильяма Лама) лаба стоит 800 долларов, самая дорогая - 150 000 долларов, средняя - 1152 доллара. Вот так выглядит схема домашней лаборатории почти за 10 миллионов рублей:

А вот за 50 тысяч рублей:

Свою домашнюю лабораторию вы можете добавить в список с помощью вот этой странички.

На Reddit коллеги заметили, что при включении технологии Turbo Boost в процессорах Intel, из виртуальной машины увеличения производительности не наблюдается. Напомним, что Turbo Boost — это технология компании Intel для автоматического увеличения тактовой частоты процессора свыше номинальной, если при этом не превышаются ограничения мощности, температуры и тока в составе расчётной мощности (TDP).

При этом емкость CPU показывается прежней, даже при создании существенной нагрузки на процессор:

В комментариях люди правильно отвечают, что поскольку Turbo Boost - это аппаратная возможность, гостевая система виртуальной машины не ловит отображение увеличения аппаратной мощности в виртуальную машину. При этом если вы посмотрите на виртуальную машину с 4 процессорами 2.4 ГГц с уровня хоста ESXi с включенным Turbo Boost до 3 ГГц, вы увидите утилизацию процессора 4*3=12 ГГц.

То есть гостевая система вполне будет использовать преимущества этой технологии, но отображать утилизацию процессора она будет в соответствии с его номинальной мощностью.

Также нужно убедиться, что ваш хост не использует политику питания High performance power management policy, которая отключает Turbo Boost. Вместо этого используйте политику Balanced, которая включена по умолчанию.

Интересные вещи делает наш коллега Jorge de la Cruz. Он скрупулезно и дотошно делает полезные дэшборды в Grafana для платформы виртуализации VMware vSphere и решения Veeam Availability Suite, которые могут помочь администраторам в решении повседневных задач мониторинга и траблшутинга.

Вот эти дашборды:

• Grafana vSphere Overview Dashboard – 8159
• Grafana vSphere Datastore Dashboard – 8162
• Grafana vSphere Hosts Dashboard – 8165
• Grafana vSphere VMs Dashboard – 8168

Чтобы сделать доступными функции визуализации этих метрик, вам потребуется развернуть следующие компоненты:

• Коллектор и нативный плагин Telegraf к VMware vSphere - агент, который собирает метрики в кластере и сохраняет их в базе данных InfluxDB.
• InfluxDB - собственно, сама база данных, хранящая метрики.
• Grafana - фреймворк, который используется для визуализации метрик из базы.

О том, как это все заставить работать, чтобы получать красивые дашборды, подробно написано вот тут и тут. Ниже мы лишь приведем примеры того, как это выглядит:

1. vSphere Overview Dashboard.

Здесь визуализуются все высокоуровневые параметры виртуальной инфраструктуры, такие как загрузка ресурсов кластера, заполненность хранилищ, состояние гипервизора и использование ресурсов виртуальными машинами.

Лайв-демо такого дэшборда доступно по этой ссылке.

2. vSphere Datastore Dashboard.

Тут можно найти все метрики, касающиеся хранилищ, включая параметры чтения и записи, и многое другое:

Лайв-демо такого дэшборда доступно по этой ссылке.

3. vSphere Hosts Dashboard.

Тут видны основные метрики с уровня хоста для каждого из серверов ESXi: конечно же, загрузка аппаратных ресурсов и сети, а также дисковые задержки (latency):

Лайв-демо такого дэшборда доступно по этой ссылке.

4. vSphere VMs Dashboard.

Здесь можно увидеть самые полезные метрики для всех виртуальных машин вашего датацентра. Здесь можно увидеть аптайм, загрузку системных ресурсов и сети, latency, счетчик CPU Ready и другое:

Лайв-демо такого дэшборда доступно по этой ссылке.

5. vSphere Hosts IPMI dashboard.

Этот дэшборд отображает информацию IPMI для серверов Supermicro и HPE, доступную через iLO. Пригодится, когда вам нужно взглянуть на статус ваших систем в распределенной инфраструктуре удаленных офисов и филиалов.

Кроме приведенных выше дэшбордов для VMware vSphere, у Jorge de la Cruz также есть несколько дэшбордов для решений Veeam Software:

• Grafana Dashboard for Veeam Availability Console - SP Overview
• Grafana Dashboard for Veeam Availability Console - Tenant Overview
• Grafana Dashboard for Veeam Backup for Microsoft Office 365 v3.0
• Grafana Dashboard for Veeam Backup for Microsoft Office 365 v3.0 - Security and Performance
• Grafana Dashboard for Veeam Backup for Microsoft Office 365 v4

Ну в заключение, стоит отметить еще один дэшборд автора - Microsoft Azure Storage.

Бывает так, что в вашей виртуальной инфраструктуре есть несколько серверов VMware vCenter, объединенных с помощью режима Linked Mode. Потом, например, вы теряете один из серверов vCenter. При этом после запуска консоли vSphere Client или vSphere Web Client на мастер-сервере vCenter вы видите предупреждение об отсутствующем сервере vCenter в объединенной конфигурации:

Could not connect to one or more vCenter Server Systems

Чтобы убрать это оповещение и привести конфигурацию в порядок, надо залогиниться на главный сервер vCenter и выполнить там следующую команду:

root@vcenter-1 [ ~ ]# /usr/lib/vmware-vmafd/bin/vmafd-cli get-ls-location --server-name localhost<br>

https://vcenter-1.home.lab:443/lookupservice/sdk<br>

Если вывод будет таким, значит у вас нет внешнего Platform Services Controller (PSC), можно продолжать исполнять команды локально. Выводим список всех узлов vCenter:

root@vcenter-1 [ ~ ]# /usr/lib/vmware-vmafd/bin/dir-cli nodes list

Enter password for administrator@sso-1.local:

Node: vcenter-1.home.lab

Type: PSC

Site: First-local

Partner #1: ldap://vc_old.home.lab



Node: vc_old.home.lab

Type: PSC

Site: First-local

Partner #1: ldap://vcenter-1.home.lab

Здесь мы видим, что у нас есть два узла в Linked-конфигурации. Чтобы удалить узел vc_old, нужно выполнить следующую команду:

cmsso-util unregister –node-pnid vc_old.home.lab –username administrator@sso-1.local

Результат будет примерно таким:

root@vcenter-1 [ ~ ]# cmsso-util unregister --node-pnid vc_old.home.lab --username administrator@sso-1.local

Password:

Solution users, computer account and service endpoints will be unregistered

2020-02-10T13:02:41.359Z Running command: ['/usr/lib/vmware-vmafd/bin/dir-cli', 'service', 'list', '--login', 'administrator@sso-1.local']

2020-02-10T13:02:41.399Z Done running command

Stopping all the services ...

All services stopped.

Starting all the services ...

Started all the services.

Success

Проверяем, что старый vCenter удален из списка:

root@vcenter-1 [ ~ ]# /usr/lib/vmware-vmafd/bin/dir-cli nodes list

Enter password for administrator@sso-1.local:

Node: vcenter-1.home.lab

Type: PSC

Site: First-local

После этого предупреждение о невозможности подключиться к серверу vCenter исчезнет из vSphere Client.

На сайте проекта VMware Labs обновился пакет USB Network Native Driver for ESXi до версии 1.4, который содержит в себе драйверы для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам необходимо подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.

Давайте посмотрим, что там появилось нового:

• Добавлена поддержка USB-устройств SuperMicro/Insyde Software Corp.
• Исправлена проблема больших кадров 9K Jumbo frames для устройств с чипсетом RTL8153.
• Устранена ошибка с неправильным отображением пропускной способности для некоторых устройств на дефолтной скорости.

Новые номера билдов теперь следующие:

• ESXi670-VMKUSB-NIC-FLING-33242987-offline_bundle-15615590.zip
• ESXi650-VMKUSB-NIC-FLING-33268102-offline_bundle-15620342.zip

Список поддерживаемых устройств на сегодняшний день выглядит так:

Скачать USB Network Native Driver for ESXi версии 1.4 можно по этой ссылке.

Не так давно мы писали о политиках хранилищ SPBM на базе тэгов в кластере VMware vSAN. Это один из механизмов категоризации объектов, который может применяться не только к хранилищам, но и хостам, виртуальным машинам и другим объектам. Появился он еще в версии VMware vSphere 5.1.

На днях компания VMware выпустила интересный документ VMware vSphere 6.7 Tagging Best Practices, в котором описаны лучшие практики по использованию тэгов в виртуальной инфраструктуре.

В документе рассматривается использование API для тэгов, работа с которым происходит через интерфейсы Java или PowerShell.

Например, вот команда по выводу всех виртуальных машин, которым назначен определенный тэг:

// List tags associated with tagId from above
// Assumes tagAssociation object from above
List retDynamicIds = tagAssociation.listAttachedObjects(tagId);

А вот так можно вывести список всех тэгов для конкретной виртуальной машины:

$allCategoryMethodSVC = Get-CisService com.vmware.cis.tagging.category
$alltagMethodSVC = Get-CisService com.vmware.cis.tagging.tag
$allTagAssociationMethodSVC = Get-CisService com.vmware.cis.tagging.tag_association
# Use first VM from above list
$useThisVMID = $useTheseVMIDs[0]
$tagList = $allTagAssociationMethodSVC.list_attached_tags($useThisVMID)

Больше интересных практических приемов работы с тэгами вы найдете в приложении к документу VMware vSphere 6.7 Tagging Best Practices.

У VMware обнаружилась полезная интерактивная инфографика, которая наглядно показывает, что происходит с дисковыми объектами виртуальных машин хоста кластера хранилищ VMware vSAN, когда его переводят в режим обслуживания (Maintenance Mode). Напомним, что о том, как это работает, мы подробно писали вот тут.

Чтобы посмотреть различные сценарии работы данного режима, нужно открыть страничку по этой ссылке и нажать на кнопку Explore maintenance mode:

Далее можно будет выбрать основные параметры перевода в этот режим.

Сначала указываем способ миграции данных:

• Full data migration - данные копируются на другие хосты таким образом, чтобы обеспечить исполнения политики FTT/RAID на оставшемся наборе хостов ESXi при введении в режим обслуживания одного или двух хостов.
• Ensure Accessibility – это миграция только тех компонентов, которые есть в кластере в единственном экземпляре. При этом, для некоторых объектов на период обслуживания не будет соблюдена политика Failures to tolerate (FTT).
• No Data Migration – в этом случае никакие компоненты не будут перемещены с хоста, поэтому некоторые ВМ могут оказаться недоступными (если на этом хосте их дисковые компоненты находятся в единственном экземпляре, а уровень RAID недостаточен для предоставления доступа к объекту).

Потом надо задать значение политики FTT и тип организации избыточности RAID0 для FTT=0, RAID1 или RAID5 для FTT=1, RAID6 для FTT=2. А далее нужно указать, один или два хоста мы переводим в режим обслуживания.

Например, если мы укажем, что нам нужен тип миграции Full data migration, при этом надо соблюсти политику FTT=2/RAID-6, то система попросит добавить еще один хост ESXi в кластер, так как оставшихся 5 хостов в этом случае будет не хватать, чтобы обеспечить требуемые политики.

Ну а при выборе выполнимого сценария будет показана анимация происходящего при переводе одного или двух хостов в режим обслуживания процесса, который вовлекает перемещение дисковых объектов виртуальных машин на другие хосты.

Надо сказать, что не рекомендуется переводить сразу 2 хоста в режим обслуживания, так как это может привести к тому, что невозможно будет обеспечить требуемые политики FTT/RAID в имеющейся аппаратной конфигурации (хотя перевод двух хостов в maintenance mode вполне поддерживается со стороны vSAN).

В общем, интересная штука - попробуйте посмотреть, как визуализируются различные сценарии.

Некоторые пользователи виртуальной инфраструктуры VMware vSphere после недавнего обновления браузера Google Chrome (а недавно вышел Chrome 80) заметили, что через vSphere Client 6.7 больше не получается подключиться:

В консоли браузера Chrome можно увидеть вот такую ошибку:

Error in connection establishment: net:: ERR_CERT_AUTHORITY_INVALID

Проблему эту подсветили наши коллеги с Reddit. Связана она с тем, что новый Chrome 80 имеет повышенные требования к безопасности и требует повторной генерации и установки сертификата с хоста ESXi. Решается проблема, как отметили в комментариях, следующим образом:

1. Идем на хост ESXi, открываем Networking -> TCP/IP stacks -> Default TCP/IP stack по ссылке: 

https://<current-hostname>/ui/#/host/networking/netstacks/defaultTcpipStack

2. Изменяем настройки хоста.

Устанавливаем Host-name (например: esx1) и Domain-name (например: my.local) и сохраняем файл.

3. Идем по ssh на хост ESXi и выполняем там следующие команды:

cd /etc/vmware/ssl
/sbin/generate-certificates

Копируем файл castore.pem на клиентский комьютер и устанавливаем его в раздел "Trusted Root Certification Authorities". Для Windows переименовываем файл castore.pem в castore.pem.cer и просто устанавливаем его двойным кликом. Выбираем Local Machine->Manual->Browse->выбираем Trusted Root Certification Authorities.

4. Перезапускаем службу хоста ESXi:

/etc/init.d/hostd restart

После этого vSphere Client через Chrome 80 должен работать без проблем.

В декабре мы писали о новой версии решения VMware OS Optimization Tool, которое предназначено для подготовки гостевых ОС к развертыванию и проведению тюнинга реестра в целях оптимизации производительности, а также отключения ненужных сервисов и запланированных задач.

В январе вышла новая версия (билд b1140) этого решения. Давайте посмотрим, что в ней появилось нового:

• Новая кнопка на экране результатов задач, которая позволяет сохранить страницу как HTML-файл.
• Новая опция, которая упрощает задачу запуска Sysprep с использованием стандартного файла ответов. Теперь можно отредактировать файл ответов до запуска Sysprep для него.
• Новая опция по автоматизации задач в рамках этапа финализации (они переехали из common options), которые запускаются как последний шаг перед тем, как Windows будет выключена, чтобы ВМ была использована в решении VMware Horizon. Она включает в себя задачи по system clean up (очистка диска, NGEN, DISM и задача Compact). Ранее эти задачи были доступны в диалоге опций командной строки. Также можно чистить лог событий, информацию о серверах KMS и отпускании IP-адреса.
• Новая вкладка опций Security - она позволяет быстро выбрать наиболее частые настройки безопасности. Они относятся к Bitlocker, Firewall, Windows Defender, SmartScreen и HVCI.
• Добавлен параметр командной строки -o для запуска утилиты без применения оптимизаций (например, clean up).
• Изменена дефолтная настройка на "не отключать Webcache", потому что это приводило к невозможности для браузеров Edge и IE сохранять файлы.
• Обновлено руководство пользоватея VMware Operating System Optimization Tool Guide (скоро обновят и второе руководство - Creating an Optimized Windows Image for a VMware Horizon Virtual Desktop).

Скачать VMware OS Optimization Tool можно по этой ссылке.

На сайте проекта VMware Labs появилась очередная интересная штука - утилита Pallas. Нужна она тем, у кого серверы ESXi находятся в изолированной относительно средств vCenter управления среде (за сетевыми экранами и далеко).

Понадобиться, например, это может в следующих случаях:

• У вас несколько хостов ESXi, которые работают в полностью изолированной сети, но у вас есть требование по управлению ими из публичной сети.
• Ваш хост ESXi не имеет кабельного соединения с сетью и должен быть подключен через WiFi или мобильное подключение. Например, ESXi работает на нефтяной вышке или в вагоне поезда, а вам нужно безопасно управлять этим хостом с сервера vCenter.
• Ваш ESXi работает на IoT-компьютере (edge-девайс), а вам нужно удаленное управление таким хостом (патчинг, создание ВМ и т.п.).

Для этих целей создается специальная агентская виртуальная машина (Dominate agent VM), в которую напрямую (через pass-through) пробрасывается устройство, которое дает интернет (например, LTE-модем). Такая ВМ уже, в свою очередь, взаимодействует с хостом через ESXi SDK для выполнения функций управления (например, передача команд по развертыванию новой ВМ).

Эта машина взаимодействует уже с Pallas Manager через протокол MQTT, который не разрешает любые входящие соединения, то есть инфраструктура оказывается защищенной от доступа извне. Больше деталей об этом продукте можно узнать из видео ниже:

Документация по проекту Pallas находится здесь (просто выберите PDF из комбо-бокса загрузки), а скачать сам виртуальный модуль в формате OVA можно по этой же ссылке.

Как знают многие администраторы решения для виртуализации и доставки настольных ПК предприятия VMware Horizon 7, при использовании графических карт NVIDIA есть возможность применять режим vSGA, обеспечивающий использование общего графического адаптера несколькими виртуальными машинами. Режим vSGA - это самый простой и эффективный способ использовать аппаратное ускорение для графики в виртуальных машинах.

Недавно в компании VMware провели тестирование производительности режима vSGA на платформе VMware Horizon 7, сравнив его с программным CPU-only, с одной стороны, и режимом GRID vGPU, с другой. Забегая вперед скажем, что конечно же vSGA показал лучшие результаты, чем CPU-only, при этом общий уровень оказался не сильно хуже, чем оптимизированный режим GRID vGPU.

Итак, давайте посмотрим на тестовую конфигурацию (тесты проводились как внутри десктопной ВМ на хосте, так и из клиента Horizon Client, расположенного на этом же хосте, чтобы убрать воздействие сетевого взаимодействия на тест):

С точки зрения программного обеспечения, использовались следующие рабочие нагрузки:

• Приложения Microsoft Office
• Adobe Acrobat для открытия документов
• Воспроизведение видео с YouTube
• Просмотрщики CAD-файлов
• Движок WebGL

Эксперимент 1

В первом эксперименте записывалось содержимое экрана пользователей (напрямую в VDI-десктопе, без использования удаленного протокола доступа) в трех конфигурациях и сравнивалось в разрезе двух основных показателей:

• Отображаемое число кадров в секунду (frames per second, FPS)
• Плавность картинки в десктопе vSGA в сравнении с CPU-only десктопом

Результатом первого теста для vSGA (анимация в PowerPoint) является более плавная картинка с большим числом FPS (поэтому запись с vSGA длится дольше):

Эти параметры численно нормализовали к уровню для vGPU и представили на графике (чем выше столбики, тем лучше):

Также в рамках этого эксперимента в PowerPoint запустили еще небольшое видео, чтобы наглядно продемонстрировать преимущество vSGA:

Эксперимент 2

Во время второго эксперимента в VMware запускали воспроизведение видео в PowerPoint из клиента Horizon Client. Там были проанализированы скриншоты видео, чтобы подсчитать FPS во всех трех режимах (CPU-only, vSGA и vGPU). Результаты также нормализовали к уровню vGPU:

На правом графике также показано нормализованное число артефактов, возникающих при отображении видео - в режиме CPU-only их достаточно много, и это видно невооруженным глазом.

Также в рамках эксперимента сравнили скриншоты, сделанные из видео на YouTube, напрямую в десктопе без удаленного доступа по протоколу PCoIP:

Очевидно, что в vSGA картинка более четкая. А вот при сравнении vGPU и vSGA уже нет столь явного различия:

Эксперимент 3

В этом эксперименте в десктопе просто запустили бенчмарк WebGL для трех режимов - CPU-only, vSGA и vGPU.

Обратите внимание, как плохо справляется режим CPU-only с тестом Aquarium. Ну и в целом видно, что vSGA работает вполне сносно, хотя и не дотягивает до vGPU.

Выводы тестирования очевидны - используйте vSGA и vGPU, если в ваших десктопах пользователи работают с графикой. Это существенно увеличивает производительность и плавность картинки. Кстати, если вы используете vSGA, то сможете делать vMotion виртуальных машин между хостами, даже если на них стоят разные графические адаптеры, а вот для vMotion с vGPU нужно унифицировать хост-серверы в этом плане (включая одинаковые версии драйверов).

На днях компания VMware сделала анонс о грядущих изменениях в лицензировании платформы виртуализации VMware vSphere. Теперь понятие "лицензия на CPU" будет включать в себя процессоры, которые содержат до 32 физических ядер.

Если в процессоре больше ядер, то квантоваться они будут по 32 штуки - то есть, если в физическом CPU 64 ядра, то вам потребуется 2 лицензии VMware vSphere (2x32). Надо понимать, что речь идет о физических ядрах процессоров, а не о логических, доступных через Hyper-threading.

Процессоры с таким количеством ядер уже не за горами - например, AMD анонсировала процессор Ryzen 9 3990X с 64 ядрами, который будет стоить $4 000 (его обещают выпустить уже 7 февраля). Intel уже продает процессор Xeon Platinum 8280 с 28 ядрами на борту, но скоро в соревновании с AMD неизбежно надо будет делать больше ядер - так что изменения в лицензировании vSphere уже скоро станут вполне актуальны.

Наглядно новую схему лицензирования процессоров можно представить так:

Данные изменения вступят в силу 2 апреля 2020 года, но до 30 апреля действует grace period - то есть до этой даты вы сможете купить и лицензировать хосты VMware ESXi по старым правилам (очевидно, что VMware потребует доказательства приобретения и самих серверов до этой даты). Поэтому если до этого времени вдруг у ваших процессоров окажется очень много ядер - самое время будет приобрести лицензии VMware vSphere впрок.

В августе прошлого года мы писали о решении VMware Project Octant, которое предназначено для визуализации кластера Kubernetes на дэшборде с точки зрения пространств имен и объектов, которые они содержат. Также там отображаются связи объектов и ресурсов. В отличие от дэшборда Kubernetes, Octant запускается локально на вашей рабочей станции, что позволяет избежать проблем, связанных с требованиями к безопасности.

Так вот, это средство постоянно обновляется со стороны VMware, и недавно были выпущены обновления Octant 0.10 и 0.10.1. Давайте посмотрим, что там появилось интересного:

• Теперь прямо из веб-браузера можно выполнять команды для исполняемых сейчас контейнеров. Для этого нужно выбрать Pod, после чего контейнер в нем, где есть ссылка Execute Command:

При выполнении команд вы будете видеть терминал в интерактивном режиме:

• Вторая интересная возможность - это Workload Viewer, позволяющий посмотреть информацию об использовании ресурсов оборудования рабочими нагрузками (и входящими в них Pods). Для этого надо выбрать раздел Workloads и кликнуть на нужный workload для просмотра информации о нем:

• Прочие улучшения. Среди них можно отметить:
  • Клавиши быстрого доступа для часто выполняемых команд
  • Добавлена поддержка API для v1 и v1beta1 CRD
  • Метаданные объектов вынесены на отдельную вкладку
  • Множество небольших улучшений и исправлений ошибок

Все изменения Project Octant 0.10.0 и 0.10.1 приведены здесь и здесь, соответственно. Загрузить Octant можно по этой ссылке в разделе Assets. Основной репозиторий проекта находится тут.